home *** CD-ROM | disk | FTP | other *** search
-
-
-
- place(n) Tk Commands
-
-
-
- _________________________________________________________________
-
- NAME
- place - Geometry manager for fixed or rubber-sheet placement |
-
- SYNOPSIS |
- place _w_i_n_d_o_w _o_p_t_i_o_n _v_a_l_u_e ?_o_p_t_i_o_n _v_a_l_u_e ...? |
-
- place configure _w_i_n_d_o_w _o_p_t_i_o_n _v_a_l_u_e ?_o_p_t_i_o_n _v_a_l_u_e ...? |
-
- place forget _w_i_n_d_o_w |
-
- place info _w_i_n_d_o_w |
-
- place slaves _w_i_n_d_o_w |
- _________________________________________________________________
-
-
- DESCRIPTION
- The placer is a geometry manager for Tk. It provides simple
- fixed placement of windows, where you specify the exact size
- and location of one window, called the _s_l_a_v_e, within another
- window, called the _m_a_s_t_e_r. The placer also provides
- rubber-sheet placement, where you specify the size and loca-
- tion of the slave in terms of the dimensions of the master,
- so that the slave changes size and location in response to
- changes in the size of the master. Lastly, the placer
- allows you to mix these styles of placement so that, for
- example, the slave has a fixed width and height but is cen-
- tered inside the master.
-
- If the first argument to the place command is a window path
- name or configure then the command arranges for the placer
- to manage the geometry of a slave whose path name is _w_i_n_d_o_w.
- The remaining arguments consist of one or more _o_p_t_i_o_n-_v_a_l_u_e
- pairs that specify the way in which _w_i_n_d_o_w's geometry is
- managed. If the placer is already managing _w_i_n_d_o_w, then the
- _o_p_t_i_o_n-_v_a_l_u_e pairs modify the configuration for _w_i_n_d_o_w. In
- this form the place command returns an empty string as
- result. The following _o_p_t_i_o_n-_v_a_l_u_e pairs are supported:
-
- -in _m_a_s_t_e_r
- _M_a_s_t_e_r specifes the path name of the window relative to
- which _w_i_n_d_o_w is to be placed. _M_a_s_t_e_r must either be
- _w_i_n_d_o_w's parent or a descendant of _w_i_n_d_o_w's parent. In
- addition, _m_a_s_t_e_r and _w_i_n_d_o_w must both be descendants of
- the same top-level window. These restrictions are
- necessary to guarantee that _w_i_n_d_o_w is visible whenever
- _m_a_s_t_e_r is visible. If this option isn't specified then
- the master defaults to _w_i_n_d_o_w's parent.
-
- -x _l_o_c_a_t_i_o_n
-
-
-
- Tk 1
-
-
-
-
-
-
- place(n) Tk Commands
-
-
-
- _L_o_c_a_t_i_o_n specifies the x-coordinate within the master
- window of the anchor point for _w_i_n_d_o_w. The location is
- specified in screen units (i.e. any of the forms
- accepted by Tk_GetPixels) and need not lie within the
- bounds of the master window.
-
- -relx _l_o_c_a_t_i_o_n
- _L_o_c_a_t_i_o_n specifies the x-coordinate within the master
- window of the anchor point for _w_i_n_d_o_w. In this case
- the location is specified in a relative fashion as a
- floating-point number: 0.0 corresponds to the left
- edge of the master and 1.0 corresponds to the right
- edge of the master. _L_o_c_a_t_i_o_n need not be in the range
- 0.0-1.0.
-
- -y _l_o_c_a_t_i_o_n
- _L_o_c_a_t_i_o_n specifies the y-coordinate within the master
- window of the anchor point for _w_i_n_d_o_w. The location is
- specified in screen units (i.e. any of the forms
- accepted by Tk_GetPixels) and need not lie within the
- bounds of the master window.
-
- -rely _l_o_c_a_t_i_o_n
- _L_o_c_a_t_i_o_n specifies the y-coordinate within the master
- window of the anchor point for _w_i_n_d_o_w. In this case
- the value is specified in a relative fashion as a
- floating-point number: 0.0 corresponds to the top edge
- of the master and 1.0 corresponds to the bottom edge of
- the master. _L_o_c_a_t_i_o_n need not be in the range 0.0-1.0.
-
- -anchor _w_h_e_r_e
- _W_h_e_r_e specifies which point of _w_i_n_d_o_w is to be posi-
- tioned at the (x,y) location selected by the -x, -y,
- -relx, and -rely options. The anchor point is in terms
- of the outer area of _w_i_n_d_o_w including its border, if
- any. Thus if _w_h_e_r_e is se then the lower-right corner
- of _w_i_n_d_o_w's border will appear at the given (x,y) loca-
- tion in the master. The anchor position defaults to
- nw.
-
- -width _s_i_z_e
- _S_i_z_e specifies the width for _w_i_n_d_o_w in screen units
- (i.e. any of the forms accepted by Tk_GetPixels). The
- width will be the outer width of _w_i_n_d_o_w including its
- border, if any. If _s_i_z_e is an empty string, or if no
- -width or -relwidth option is specified, then the width
- requested internally by the window will be used.
-
- -relwidth _s_i_z_e
- _S_i_z_e specifies the width for _w_i_n_d_o_w. In this case the
- width is specified as a floating-point number relative
- to the width of the master: 0.5 means _w_i_n_d_o_w will be
-
-
-
- Tk 2
-
-
-
-
-
-
- place(n) Tk Commands
-
-
-
- half as wide as the master, 1.0 means _w_i_n_d_o_w will have
- the same width as the master, and so on.
-
- -height _s_i_z_e
- _S_i_z_e specifies the height for _w_i_n_d_o_w in screen units
- (i.e. any of the forms accepted by Tk_GetPixels). The
- height will be the outer dimension of _w_i_n_d_o_w including
- its border, if any. If _s_i_z_e is an empty string, or if
- no -height or -relheight option is specified, then the
- height requested internally by the window will be used.
-
- -relheight _s_i_z_e
- _S_i_z_e specifies the height for _w_i_n_d_o_w. In this case the
- height is specified as a floating-point number relative
- to the height of the master: 0.5 means _w_i_n_d_o_w will be
- half as high as the master, 1.0 means _w_i_n_d_o_w will have
- the same height as the master, and so on.
-
- -bordermode _m_o_d_e
- _M_o_d_e determines the degree to which borders within the
- master are used in determining the placement of the
- slave. The default and most common value is inside.
- In this case the placer considers the area of the mas-
- ter to be the innermost area of the master, inside any
- border: an option of -x 0 corresponds to an x-
- coordinate just inside the border and an option of
- -relwidth 1.0 means _w_i_n_d_o_w will fill the area inside
- the master's border. If _m_o_d_e is outside then the
- placer considers the area of the master to include its
- border; this mode is typically used when placing _w_i_n_d_o_w
- outside its master, as with the options -x 0 -y 0
- -anchor ne. Lastly, _m_o_d_e may be specified as ignore,
- in which case borders are ignored: the area of the
- master is considered to be its official X area, which
- includes any internal border but no external border. A
- bordermode of ignore is probably not very useful.
-
- If the same value is specified separately with two different
- options, such as -x and -relx, then the most recent option
- is used and the older one is ignored.
-
- The place slaves command returns a list of all the slave |
- windows for which _w_i_n_d_o_w is the master. If there are no
- slaves for _w_i_n_d_o_w then an empty string is returned.
-
- The place forget command causes the placer to stop managing
- the geometry of _w_i_n_d_o_w. As a side effect of this command
- _w_i_n_d_o_w will be unmapped so that it doesn't appear on the
- screen. If _w_i_n_d_o_w isn't currently managed by the placer
- then the command has no effect. Place forget returns an
- empty string as result.
-
-
-
-
- Tk 3
-
-
-
-
-
-
- place(n) Tk Commands
-
-
-
- The place info command returns a list giving the current
- configuration of _w_i_n_d_o_w. The list consists of _o_p_t_i_o_n-_v_a_l_u_e
- pairs in exactly the same form as might be specified to the
- place configure command. If the configuration of a window
- has been retrieved with place info, that configuration can
- be restored later by first using place forget to erase any
- existing information for the window and then invoking place
- configure with the saved information.
-
-
- FINE POINTS
- It is not necessary for the master window to be the parent
- of the slave window. This feature is useful in at least two
- situations. First, for complex window layouts it means you
- can create a hierarchy of subwindows whose only purpose is
- to assist in the layout of the parent. The ``real chil-
- dren'' of the parent (i.e. the windows that are significant
- for the application's user interface) can be children of the
- parent yet be placed inside the windows of the geometry-
- management hierarchy. This means that the path names of the
- ``real children'' don't reflect the geometry-management
- hierarchy and users can specify options for the real chil-
- dren without being aware of the structure of the geometry-
- management hierarchy.
-
- A second reason for having a master different than the
- slave's parent is to tie two siblings together. For exam-
- ple, the placer can be used to force a window always to be
- positioned centered just below one of its siblings by speci-
- fying the configuration
-
- -in _s_i_b_l_i_n_g -relx 0.5 -rely 1.0 -anchor n -bordermode outside
-
- Whenever the sibling is repositioned in the future, the
- slave will be repositioned as well.
-
- Unlike many other geometry managers (such as the packer) the
- placer does not make any attempt to manipulate the geometry
- of the master windows or the parents of slave windows (i.e.
- it doesn't set their requested sizes). To control the sizes
- of these windows, make them windows like frames and canvases
- that provide configuration options for this purpose.
-
-
- KEYWORDS
- geometry manager, height, location, master, place, rubber
- sheet, slave, width
-
-
-
-
-
-
-
-
- Tk 4
-
-
-
-